A dream of a better OS

  • file descriptors capabilities are great; everything should be a "file descriptor" (not a file!); let's have file descriptors on steroids, "objects", capabilities.
  • Memory-safe isolated-state modules with clear interfaces ("objects"): WASM, eBPF-like? Objects should not be too small.
  • modulekernel: modules can be instantiated/moved anywhere needed (no matter if kernel/userspace process): monolithic vs microkernel should not matter much.
  • handle/crypto/capability-based access control; rwxr-x--- was stupid even in the 80s.
  • JIT-compilation, machine code caching; machine architecture is a runtime detail; a kernel image is used to bootstrap (like Inferno).
  • events should be well-defined and first-class. Less ad-hoc mechanisms like fsnotify or POSIX signals (pidfd/signalfd is better?).
  • hierarchical namespaces are great
    but don't overdo it

    `C:\Program Files\Microsoft Visual Studio Enterprise Edition\Framework\The Epic Microsoft Framework of 2018\Toolchains\The Epic Microsoft Toolchain of 2018\Version\The Epic Version of the Microsoft Toolchain 2018\` ...

  • but: single dispatch can be limiting.
  • fully typing everything would be great, but let's have at least basic shape of data everywhere (like JSON)

Data

(Semi-)structured data at OS level:

  • at least XML/JSON-like semistructure.
  • WIT/capnproto(-like) interfaces on top of that.
  • typed data: capnproto(-like) schemas everywhere (but: distributed systems?);

Hypertext everywhere:

  • addressing: identifiers for objects; urls? schemas? Local vs global identifiers.
  • encoding: e.g. use custom plane in Unicode? Out-of-band information? Bad old escape sequences?
  • Plan9's plumbers? Smalltalk/Oberon's every-text-is-a-command? Sounds like magic out of thin air though (symbols are not denotations).

Q: global identifiers, global namespaces: on top of DNS?

Interprocess communication

  • runtime magically chooses the best mechanism for a IPC channel: messages in CPU registers, small copies, zero-copy shared memory queue, network socket/RDMA.
  • zero-copy shared memory queues for bulk data transfer; producer/consumer can run on different cores in parallel to communicate locklessly;
  • clear ownership of memory; mutable XOR shared as much as possible.

Networking and RPC

  • mime-typing everything, also with capnp/<UUID>?
  • a well-defined, capnproto(-like) language-agnostic system ABI; no stinking C ABI.
  • every kernel/system/IPC interface must be a well-typed RPC; even signals to be implemented like signalfd.
  • system-level schema registry, pubsub and service discovery;

Storage:

  • reconciles (capnproto-like) structured data and large buffers. POSIX sucks at databases.
  • more log-structured, append-oriented to behave well in distributed systems.
  • transactional
  • build off SQLite at first?

Resource control

  • different resource-control personalities for interactive and server/batch use.

(G)UI

Not-adhoc, emacs-like GUI:

  • gradual reification of abstraction: keyboard shortcuts -> functions -> abstract model; events as first-class objects
  • virtual "DOM" (at least as an OS interface) and named elements to enable scripting everywhere. Bonus: accessibility. Bonus: auto-GUI representing structure, can (and should!) be overriden by a custom spec (~"CSS").
  • good visibility into internals by default: Oberon-like system log, htop-like view into processes/resources, resource graphs and dashboards. The system exports objects, they get a default GUI + optional enhancements/alternative GUIs. But: keep it humane, limited and task-oriented?
  • GUI apps "stacking": an app input/output is not necessarily produced/consumed by a human; similar to pipelines in shell. Input/output areas (~"CQRS", e.g. output-only views).
  • gradual enhancement of shell: should have hooks for deep GUI integration and rich formatting/layout (see: arcan-fe terminal), while still usable on dumb sequential terminals (somehow, custom escape sequences again? multiplexing? out-of-band does not really work over e.g. UART).
  • wayland-like compositing, framebuffers should be isolated; login and screen lock should be handled in a special, secure way. A secure area on the screen/touchbar that is always used only by OS (might be dimmed for "full-screen" apps).
  • floating windows are useful, but overrated; more thought to tiled and stacked interfaces. No stinking message boxes and wizzards;
  • menus are good, searchable menus (a la macOS) are a must.
  • search and tree-shaped history everywhere: clipboard, windows, processes, browsing history, tabs, editing, objects in images and videos; semantic "distance" and clustering?
  • too much hierarchy is no longer a system; but: a systematic view is needed too; namespaces and clear paths are good?

Notes from mobile Sculpt

See: https://genodians.org/nfeske/2023-01-05-mobile-user-interface

  • appliance role: a trusted system UI for managing physical aspects of the device. This UI should be completed, fixed and finished.
  • user-defined functionality: apps; flexible, unanticipated tasks. Users need to run useful, but untrusted apps.

The appliance UI plane is split into five fixed sections: "Device", "Phone", "Storage", "Network", "Software".

Existing examples

Look at Plan9 to know how to make it flexible. Do not copy its atrocious UI though.

Look at mobile UIs.

This sounds suspiciously like Fuchsia.

What gets reinvented again and again

What gets reinvented over and over again?

  • logging
  • memory management, garbage collection
  • containers, isolation?

Misc

  • file manager is not an application, it's a component to be used, embedded and customized by applications. Or the other way around: it should be an invisible omnipresent environment?
  • variable environment is a key-value map.
  • process arguments are a key-value map.
  • configuration is usually is a key-value map.

Ref: